
@title{GDB}{Generic Database Reference}

 PCI's Works programs, and some PACE programs use the Generic DataBase 
 library (GDB) to access image and auxiliary information from data files.
 This allows different file types to be used interchangeably where it makes 
 sense for the file type.  

 Most file types do not support all types of possible data and access.
 In fact only PCIDSK files support all possible data types.  The following 
 topics will discuss the level of support and user implementation details
 for each of the supported file types.
 
1	Supported File Formats
@keyword{Formats!Supported}

 The following file types are supported by the Generic DataBase library.

2	ADRG
@index{ADRG CD-ROM}
@keyword{ADRG}{DIGEST}{CDROM}{CD-ROM}

 ADRG, a specific form of "DIGEST" data distributed on CD-ROM is
 supported by the GDB layer.  ADRG CD-ROMs typically contain 3 image
 channels and one or more images.

 Users should select the ".GEN" file which is located in a
 subdirectory on the disk.  The name of this subdirectory varies with
 each disk.  An example name is "/cdrom/jaus0101/jaus0101.gen".

 To select an image other than the default image, the image number is
 specified as if it were a file in the ".GEN" file's directory.  As an
 example, "/cdrom/cous0101/cous0101.gen/2" would select the second
 file on a disk.

 Georeferencing information is gathered from the disk, but other text
 and descriptive information is not.  Writing an ADRG disk is not
 supported by the GDB layer.

 See Also: FIMPORT

2	Arc/Info Generate
@index{Arc/Info!Generate}{Generate (ArcInfo)}
@keyword{Arc/Info Generate}

 Arc/Info Generate (or Ungenerate) files are supported by the GDB library.
 They are represented as a single vector segment, with no other auxiliary
 information.

 Generate files do not contain any georeferencing information, so the 
 vectors are
 assigned a georeferencing type of METRE.  Generate files contain one
 numeric attribute which is imported and exported with the vector data.

 Generate files may be created by Works programs, and the FEXPORT PACE program.
 Also, the PACE programs VECREAD and VECWRIT may be used to access Generate 
 files, although these programs are not as reliable as FIMPORT and FEXPORT.

 See Also: {WORKS|Data File|File Creat}Works Create File, 
	   VECREAD, VECWRIT, FIMPORT, FEXPORT, {..|Arc/Info GRID}Grid

2	Arc/Info Grid
@index{Arc/Info!Grid}
@keyword{Arc/Info Grid}

 Arc/Info ASCII Grid files are supported by the GDB library.  This file
 format is compatible with the Arc/Info ASCIIGRID and GRIDASCII
 commands, and consists of one raster layer.

 The ASCII Grid format is supported for import, and export and is always
 represented as a single 16 bit signed raster layer.   It is likely that 
 floating point grid files will not work at all.

 If a ``.prj'' file is in the same directory as the grid file, and has the
 same basename as the grid file it will be read to obtain projection 
 information.  Currently the only recognised projecion is UTM.  All other
 files will be imported with a MAPUNITS string of ``METRE''.

 Is is not possible to LINK to Grid files as they are ASCII encoded.

 See Also: FIMPORT, FEXPORT, {..|Arc/Info Generate}Generate	

2	Arc/Info Import/Export
@index{Arc/Info!Import}
@index{Arc/Info!Export}
@keyword{Arc/Info Import Export ESRI}

 Arc/Info Import/Export files are supported by the GDB library for read
 operations only.  Compressed forms of 
 these files are not supported at this time.  The file is represented as a 
 single vector segment, and assigned a georeferencing type of METRE.  

 Currently the ARC layer is read in as polylines with the USERID as the 
 attribute.  The CNT (Centriods) and LAB (Labels) section are read in as 
 points, and may contain attribute information.  Structures read in from 
 ARC, CNT or LAB sections will have a corresponding GROUP of 1,2 and
 3 respectively.

 Import/Export files may be read by Works programs and the FIMPORT PACE 
 program.

 See Also: FIMPORT, {..|Arc/Info Generate}Generate	

2	Arc/Info Shapefile
@index{Arc/Info!Shapefile}
@keyword{Shapefile Arc/Info ESRI ArcView}

 Arc/Info Shapefile files are supported by the GDB library for import and
 export.  The Shapefile format contains vector and attribute information.
 Typically, datasets include three files, with a common basename and the 
 extensions .shp, .shx, and .dbf.  Shapefiles do not contain projection 
 information
 so all vectors will be reported as being in the georeferencing system  
 "METRE" when imported.

 Shapefiles are currently supplied in four types, POINT, ARC, POLYGON, and
 MULTIPOINT.  The POLYGON and MULTIPOINT layer types contain what ESRI calls
 multi-part shapes.  For instance, a multipart polygon would be the outer
 boundary, and all the interior holes in the polygon.  At this time the
 shapefile translator does not preserve the parts information, instead 
 merging all the parts of a shape into a simple vertex list.

 The shapefile attributes are stored in an xBase (.dbf) file which is also 
 supported as a standalone GDB format.  Further details on the .dbf translator
 can be found in the xBase topic.

 Shapefiles are produced by ArcView 2, and Arc/Info.  Within Arc/Info use
 the ARCSHAPE command to export a coverage to a shapefile, or the SHAPEARC
 command to import a shapefile and build a coverage.

 See Also: {..|}xBase, FIMPORT, FEXPORT

2	Aries Image Format (DIPIX)
@index{DIPIX (Aries) Image Format}
@keyword{Aries}{DIPIX} 

 Some Aries (DIPIX) image files (.i suffix) are supported by the GDB 
 library.  Only integer files (16/32 bit) are supported.

 Existing Aries files may be written to, but new files cannot be created
 by Works programs.  

 See Also: LINK

2	AutoCAD DXF
@index{AutoCAD DXF Format}{DXF Format}
@keyword{AutoCAD DXF}

 AutoCAD vectors in the form of a DXF (Data Interchange File)
 file are supported by the GDB library
 for both read or write operations, with certain limitations.

 For read operations the only entities supported are the POINTs, LINEs,
 POLYLINEs and SOLIDs.  ARCs and CIRCLEs are also supported by approximating 
 them with line segements.

 TEXTs are also supported: the character string is stored in the
 "TextString" attribute and the orientation in the "Angle" attribute.

 Unsupported entities are represented by a point.  The
 coordinate of this point is the first X,Y,Z coordinate of the unsupported 
 entity.

 If some layers are defined in the TABLES section then one segment
 will be created for each of them otherwise all entities will
 be on the same layer.

 In read access, a Representation Table (RST) is built based on the drawing 
 information that is available (line width, LTYPEs, etc).  Since this
 table is built while reading the file, it should be queried only after
 the file has been completely read in.  Each entity read is given a
 "REPCode" attribute that points to an entry in this RST.  Finally there
 is only one RST for the whole file, even if there are several layers.

 For write operations the only entites that are written out for now are, 
 LINE and POINT entities.  Any ARC or CIRCLE entities that may have 
 been read in will be written out has a series of approximating line 
 segments.  And TEXTs will be written out as simple POINT entities.

 It is also possible to provide a RST when exporting.  In this case the
 line types and TEXTs will be written back to the file.
 
 AutoCAD DXF files may be created by Works programs as well as PACE.  
 The PACE programs FIMPORT and FEXPORT may also be used to import and 
 export DXF vector data.

 See Also: {WORKS|Data File|File Creat}Works Create File, 
	   FIMPORT, FEXPORT

2	BMP
@index{Windows BMP Format}{OS/2 BMP Format}
@keyword{BMP BuMP Windows OS/2}

 Windows and OS/2 BMP files are simple raster files.  They are a
 common import and export format for applications under Windows and
 OS/2.

 GDB supports the image variants that have 1, 8, or 24 bits per
 pixel.  BMP files must be uncompressed to be read by GDB. 
 GDB will produce a 24-bit file if three channels are saved,
 an 8-bit file if one channel is saved, and a 1-bit file if a bitmap
 is saved.  It is not legal to specify any other number of channels.

 GDB will update any type of supported BMP file, but if asked to
 create a BMP file, it will create the Windows variant.  For FEXPORT, 
 use the type name "BMP" to specify the BMP format.

 See Also: FIMPORT, FEXPORT

2	CCOGIF
@index{CCOGIF}
@keyword{CCOGIF}

 The GDB library supports the CCOGIF 2.3 vector format.  This format
 was produced by the Canadian Council on Geomatics as a standard file
 exchange format for digital spatial data.  

 Only read access to CCOGIF format is available.  No attributes are 
 imported with CCOGIF vectors, and the ``area'' structure is ignored.  

 Projection information is extracted from the CCOGIF file; however, only
 the Transverse Mercator (TM) projection has been tested. 

 See Also: FIMPORT

2	DEM (USGS Digital Elevation Model)
@keyword{USGS File Formats}{DEM (USGS)}

 USGS 7.5 minute, and 1 degree ASCII DEM files are supported for reading 
 by the GDB library.  USGS DEM files contain one 16 bit channel of 
 elevation data, and no auxiliary data.  The UTM georeferencing information 
 for the elevation data is also loaded from the DEM file.

 The Works programs currently do not support writing to an existing 
 USGS DEM file, or creating new ones.  

 By definition USGS DEM files are supposed to be based on the NAD 27
 (E0) datum; however, PCI has seen some that where based on the NAD 83
 datum.  However, the GDB library cannot detect this, and will always 
 report DEM files as being E0 (NAD27).

 The PACE tasks DEMREAD and DEMWRIT may also be used to read and write
 USGS DEM files.

 See Also: DEMREAD, DEMWRIT, FIMPORT

2	DLG (USGS Digital Line Graph)
@keyword{USGS File Formats}{DLG}{Digital Line Graphs}

 USGS DLG (Digital Line Graphs) are supported for reading and writing by the
 GDB Library. The full topology of a DLG file is not retained during a read 
 operation.  Any Area information present in a DLG file will not be retained. 
 In addition only the first attribute code of a line will be retained; all 
 others will be skipped.

 DLG files written out by this program are equivalent to DLG level 2 files. 
 When DLG files are written out, a node list is generated, and node to line as
 well as line to node linkages are generated.  Since the full topology of the
 file is not retained, the left and right area fields of a Line Record will
 be initialized with a -1.

 USGS DLG files may be created by Works programs.  The DLGREAD and DLGWRIT
 programs may also be used to import and export DLG format vector data.

 See Also: {WORKS|Data File|File Creat}Create File, 
	   DLGREAD, DLGWRIT, FIMPORT

2	DOQ (USGS Digital Orthophoto Quadrangle)
@keyword{USGS File Formats}{Digital Orthophoto Quadrangle}

 USGS digital orthophotos are supported by the GDB library for
 read only. Digital orthophotos with embedded DEM information are not 
 supported. 

 Georeferencing information (always UTM) is extracted from DOQ files, 
 but auxiliary information cannot be accessed.

 Existing DOQ files can be written to, but new files cannot be created.
 The PACE program LINK may also be used to access DOQ image data.

 See Also: LINK, FIMPORT

2	DTED
@keyword{DTED}

 The DMA's (Defense Mapping Agency) DTED (Digital Terrain Elevation Data) 
 format is supported by the GDB library for reading and writing. Note
 that writing is only supported for existing DTED files and there are no 
 provisions for createing a new DTED file.

 The GDB layer supports the CD-ROM DTED format. Under the specification,
 these files have an extension .dt1. They contain a user header label,
 data set identification record, accuracy description record, and the
 digital elevation information. The CD-ROM DTED format also implies
 a hierarchical arrangement of files based on georeferencing. The GDB
 layer does not understand this hierarchy and only knows how to read
 a single .dt1 file.

 A DTED file covers a 1 degree by 1 degree area but its resolution
 varies depending on which zone the file covers as well as what 
 level the DTED file is.

 DTED files contain one 16 bit channel of elevation data and no auxiliary
 data. The UTM georeferencing information for the elevation data is also
 loaded from the DTED file. DTED data is based on the WGS84 (E012) datum.

 The Works programs currently support writing to an existing DTED file,
 but not createing new ones.  

 The PACE task MIDTED can be used to read DTED files from tape into a 
 PCI .pix database. 

 See Also: MIDTED, FIMPORT

2	EOSAT CD-ROM
@keyword{EOSAT Fast Format}{CDROM}

 EOSAT Fast Format is a tape format that has been extended to be used as a 
 CDROM distribution format.  GDB library support has been added for
 this format, at least as distributed by EOSAT, RadarSat and Indian Remote
 Sensing Center.

 The directory and naming conventions for EOSAT Fast Format CDROMs may 
 vary; however, the GDB library is only able to understand two file
 naming conventions.  It may be possible to read EOSAT Fast Format 
 CDROMs from other sources if the files are renamed to match one of
 the following conventions.  

 - RadarSat CDROMs typically name the files as follows.

  /cdrom/SCENE01/VOLD_01.DAT	<--- Select this file.
  /cdrom/SCENE01/BAND_01.DAT
  /cdrom/SCENE01/BAND_02.DAT
  /cdrom/SCENE01/BAND_03.DAT

 - EOSAT and Indian CDROMs typically name the files as follows.

  /cdrom/SAMPLES/LISS1/HEADER.DAT   <--- Select this file
  /cdrom/SAMPLES/LISS1/BAND1.DAT
  /cdrom/SAMPLES/LISS1/BAND2.DAT
  /cdrom/SAMPLES/LISS1/BAND3.DAT

 Georeferencing information may be extracted for some precision geocoded
 products.

 There is currently no support for generating EOSAT Fast Format datasets
 with EASI/PACE.

 See Also: LINK, FIMPORT, MIEOSAT

2	Erdas Imagine (.img)
@keyword{Erdas}{Imagine}

 Erdas Imagine (.img) files are supported by the GDB library for import.

 Erdas image layers can be 8-bit, 16-bit unsigned, 16-bit signed or 32-bit
 real.  Other layer types will cause access to the file to fail.
 Note that 16-bit unsigned and 16-bit signed data will be imported as 32-bit
 real.  The image layers must be uncompressed and contain no data holes.  

 Limited support for importing georeferencing information is included.  The
 input bounds are read; however, the map units will be defaulted to METRE
 except for UTM, SPCS, LONG and TM.  Note that the zone and other projection
 information is suspect even for these georeferencing systems.
 
 See Also: {..|Erdas .GIS}Erdas .GIS and .LAN, FIMPORT

2	Erdas .GIS and .LAN 
@keyword{Erdas}{GIS}{LAN}

 Erdas version 7.4 .GIS and .LAN image files are supported by the 
 GDB library.  In fact some files earlier than version 7.4 are also
 supported, but the new version 8.0 files may not be supported.

 Erdas files can be 8 bit, or 16 bit unsigned.  If georeferencing 
 information is present it will be read along with the data.  It is
 also possible to create new Erdas files in Works programs using 
 the ``New'' menu selection, and to write data to any Erdas file.

 Only the .GIS or .LAN files are read by the GDB library.  None of 
 the auxiliary or trailer files are read or generated.

 The PACE programs FIMPORT, FEXPORT, ERDASWR, ERDASRD and ERDASHD may also 
 be used to operate on Erdas files.  The program ERDASWR, ERDASRD and 
 ERDASHD are not based on the GDB library and are not considered to be as
 reliable as FIMPORT and FEXPORT.
 
 See Also: {WORKS|Data File|File Creat|Erdas}Works Create Panel, 
	   ERDASWR, ERDASRD, ERDASHD, FEXPORT, LINK, FIMPORT,
	   {..|Erdas Imagine}Erdas Imagine (.img)

2	GRASS
@keyword{GRASS}

 GRASS dig (vector) files as well as cell (raster) files are supported by the 
 GDB library for read and write operations.  

 GRASS filenames may be specified in one of two ways.  If there is a .grassrc
 file in the user's home directory, a simple filename may be given.  The file 
 will then be placed in the correct layer for the file.  If the .grassrc is 
 not present, the user must specify a path along with the filename.

 For vector files specified without a full path name and a .grassrc present, 
 the dig (binary) version of the vector file will be read or written to before 
 any ascii file.  To use an ascii vector file, a path name which includes a 
 dig_ascii directory must be specified.

 The dig_plus file is not modified when a binary file is written to.  The user 
 will have to use the grass program v.support to update the dig_plus file.

 When GRASS vectors are loaded, both Line and Area arcs are read in
 as polylines.  The dig_att file is also read and processed.
 Each line attribute is associated with its unique line arc.
 Area attributes are read in as vector points with an attribute.
 Area arcs will have an assigned attribute of 0.  No attempt
 is made to assign area attributes to their particular AREA arcs.  
 Georeferencing bounds are imported for vector layers, but the correct 
 georeferencing system is only selected for UTM.  All others are mapped to
 METER.

 When GRASS files are written, those lines read in as line arcs
 or area arcs are written out as lines or arcs respectively.
 Added lines are treated as line arcs.
 Added points will be written out as degenerate line arcs.
 Points that were read in as AREA attributes
 will not be written.  These points will be written out only to the
 dig_att file.

 The non-zero attribute of lines will be written out to the dig_att file.
 The coordinate associated with the attribute will be the midpoint
 between the first two vertices in the arc. ((P1+P2)/2)

 Any attributes read in as AREA attributes will be output unchanged
 to the dig_att file.

 The LINK PACE program can also be used to access uncompressed GRASS
 raster layers.  FIMPORT, FEXPORT and ImageWorks can be used to import and 
 export GRASS layers.
 
 See Also: {WORKS|Data File|File Creat|GRASS}Works Create Panel, 
	   LINK, FIMPORT, FEXPORT

2	GXF

 GXF Version 2.00 imagefile format is supported for import and export by
 the GDB library.  GXF format is a simple ASCII formatted raster format.
 Only one channel would exist in a GXF file, so the format would not be used
 for multispectral imagery.  Only uncompressed image data is supported.
 
 Georeferencing is read and written for GXF files.  Once a GXF file is read, 
 the georeferencing units might have to be changed from "METRE" to more
 appropriate units.

 See Also: FIMPORT, FEXPORT, LINK

2	HDF (Hierarchical Data Format)
@keyword{HDF}{Hierarchical Data Format}{NCSA}{PathFinder}

 The GDB library supports various types of .HDF raster files.  In particular
 simple eight bit raster (RI8), and Scientific Data Set (SDS) files should
 be readable.  RI8 files may be run length encoded, while only uncompressed
 SDS files are supported.

 Currently no auxiliary data or georeferencing information is extracted from
 HDF files.  

 RI8 files consist of 8-bit run length encoded, or uncompressed imagery.
 SDS files may contain 8-bit, 16-bit, or floating point image channels
 (floating point channels have not been tested).  NASA-generated PAL data
 is also supported.  The Vset extensions to HDF files are not supported.

 The HDF format was developed by the National Center for Supercomputing
 Applications (NCSA), which maintains a library for accessing HDF files,
 and various applications for displaying and operating on HDF files.

 All PCIDSK support datatypes may be exported to HDF format files using
 the FEXPORT PACE program, though exporting more than one data type in
 a single HDF file is not currently supported.  HDF files may have associated
 georeferencing information stored in an .aux file, and FEXPORT will export
 georeferencing information in an .aux file.

 See Also: LINK, FIMPORT, FEXPORT

2	HIDISK (HI-VIEW image format)
@index{HIDISK}
@keyword{HIDISK}{HI-VIEW}

 The HIDISK image format used by the Horler Information Inc. HI-VIEW software
 (Version 111) is supported by the GDB library for reading.  Writing in this
 format has not been implemented.

 8-bit unsigned, 16-bit signed, 16-bit unsigned and 32-bit real data will
 be read.  (32-bit signed integer data is not supported.)

 See Also: LINK, FIMPORT

2	Image Display Handler

 On Unix systems it is possible to access the display (ImageWorks
 or the Handler) as if it were a file, via the GDB library.  Possible 
 filenames that would refer to the display are ``VD00'', ``VD0:'', ``VD1:'',
 ``VD2:'', or ``VD3:''.

 It is possible to access the image planes of the display as channels,
 graphic planes as bitmaps, and vector layers as vector segments. 
 The LUTs and PCTs are also accessible.  The overall georeferencing (ala Set 
 Map Area) is also accessible.

 Note that the old Handler does not support georeferencing or vector layers.

 See Also: FIMPORT, CDLC, IIIC, {IWORKS}ImageWorks

2	Intergraph Raster Files
@keyword{Intergraph Raster Files}{Continuous Tone Files}{COT Files}{CFL Files}

 The GDB library supports some variants of the Intergraph Raster format. 
 No auxiliary or georeferencing information is supported for Intergraph
 Raster format files.  Intergraph raster files may have a variety of 
 extensions including .rgb, .cot and .cfl.

 The supported sub-formats are grey scale continuous tone (type 2),
 compressed RGB (type 27), and uncompressed RGB (type 28),
 (type 28 has never been tested).

 Continuous Tone files cannot be created with Works programs, but 
 the imagery on an existing file can be updated if it is not of
 type 27.  Also the PACE LINK program can be used to access Intergraph
 Raster data in type 2 and type 28 files.

 See Also: LINK, FIMPORT
 
2	Joint Photographic Experts Group (JPEG) files
@keyword{JPEG}

 The GDB library supports single scan JPEG files that contain 8 bit
 grey scale or 24 bit colour images.  GDB will read both YCC and the
 less common RGB colour space JPEG files, but will always write the
 YCC variant.

 When writing a JPEG file, all three channels must be written at the
 same time.  When reading a JPEG file, it is vastly more efficient to
 read it in a pixel interleaved fashion, but reading in a band
 interleaved fashion is supported (on average it will take three times
 longer).

 The GDB JPEG support is based on the Independent JPEG Group's (IJG)
 version 4 code.  A suite of public domain Unix tools for dealing with 
 JPEG files is available by anonymous ftp from unix.hensa.ac.uk in the 
 directory /pub/uunet/graphics/jpeg as jpegsrc.v4.tar.Z.  

 See Also: FIMPORT

2	LAS Image Format
@keyword{LAS Image Format}

 The LAS 5.0 Image File Format is supported for read access by the GDB 
 library.  The LAS format is used to store various types of geocoded
 image data.  Typically a LAS image will consist of several related files.
 The two used by the GDB library are the .ddr and .img files.  The .ddr
 files contains header information and geocoding, while the .img file
 contains the actual imagery.  Either file may be used to refer to the
 LAS image, but both must exist in the same directory with the same base
 name.

 The GDB library supports reading and updating imagery on LAS files.  In some
 circumstances it is also possible to read georeferencing information.  In
 theory any of the USGS style projections may work, (only UTM has been tested).
 There is currently no option to export imagery in LAS format.

 See Also: LINK, FIMPORT

2	Laser-Scan
@keyword{Laser-Scan}

 Five of the seven types of Laser-Scan image files are supported by 
 the GDB library.  Functions exist to read, update and create Laser
 Scan files, though image update of compressed files is not possible.

 There is no support for georeferencing, or any auxiliary data other than
 pseudo-colour tables (PCTs) with Laser-Scan files.

 The supported Laser-Scan file types are:
   - 2: Greyscale (uncompressed, LINKable)
   - 3: PseudoColoured Image (compressed)
   - 4: RGB (24-bit uncompressed, LINKable)
   - 5: Bitmap (uncompressed)
   - 7: PseudoColoured Image (uncompressed, LINKable)

 The RLE and PackBits compressed bitmap file types (1 and 6) are not supported
 at this time.

 The type 3 compressed pseudocoloured image files use a simple run length
 encoding scheme.  The image channel may not be updated after the initial
 createion.  The pseudocolour table (PCT) may be stored in a related .PAL
 file, in which case it is available to read.  If the .PAL file does not
 exist the pseudocolours are lost.  .PAL files are not created on export,
 and thus a PCT cannot be written out with a new pseudo-coloured file.

 See Also: {WORKS|Data File|File Creat|Laser}Works Create Panel,
           LINK, FIMPORT, FEXPORT

2	LaserScan IFF Text
@index{LaserScan IFF Format}{IFF Format}
@keyword{LaserScan IFF}

 The GDB library supports LaserScan's IFF text format for read, and write
 access.  The following attributes will automatically
 be created for each layer when reading an IFF file:

 - REPCode	Feature Code
 - GroupId	FSN (Feature Serial Number)
 - Angle	RO (Orientation for texts and symbols)
 - Height	AC 3
 - TextString	TX for text features
 - ChildList	Used to group features linked by invisible lines

 Layers in the IFF file will appear as separate segments when a file is
 read in.  Creation of new segments (IFF layers) is supported as well.

 Text IFF files may be created by Works programs as well as FEXPORT.  
 The PACE programs FIMPORT and FEXPORT may also be used to import and 
 export IFF vector data.

 See Also: {WORKS|Data File|File Creat}Works Create File, 
	   FIMPORT, FEXPORT

2	LGSOWG CD-ROM
@keyword{LGSOWG}{Spot Image}{ESA}{CDROM}

 LGSOWG is a magnetic tape format that can be extended to be used as
 a CD-ROM distribution format.  A GDB library support has been added for
 the base format.

 The directory structure and naming conventions may vary.  Examples
 produced by various agencies are as follows.  In each case, you would
 select the imagery file.

 - Spot Image CD-ROMs typically have a directory structure as follows.  

  /cdrom/SCENE01/VOLD_01.DAT
  /cdrom/SCENE01/LEAD_01.DAT
  /cdrom/SCENE01/IMAG_01.DAT   <--- Select this file
  /cdrom/SCENE01/TRAI_01.DAT
  /cdrom/SCENE01/NULL_01.DAT
  ...

 - ESA CD-ROMS may have the following structure.  The following example
 is organized in a BSQ (Band Sequential) format for one scene.  Each
 band of the scene is in a separate file, so you would select and then
 display the imagery, for as many bands as you want.

  ...
  /cdrom/scene1/lea_01.001
  /cdrom/scene1/dat_01.001      <--- Select this file and load imagery
  /cdrom/scene1/tra_01.001

  /cdrom/scene1/lea_02.001
  /cdrom/scene1/dat_02.001      <--- Select this file and load imagery
  /cdrom/scene1/tra_02.001
  ...

 - RadarSat CD-ROMS may have the following structure.

  /cdrom/lgsowg/vold_01.dat
  /cdrom/lgsowg/lead_01.dat
  /cdrom/lgsowg/imag_01.dat     <--- Select this file
  /cdrom/lgsowg/trai_01.dat
  /cdrom/lgsowg/null_01.dat

 - CCRS CD-ROMS may have the following structure.

  /cdrom/me0072/me0072.vol
  /cdrom/me0072/me0072.ldr
  /cdrom/me0072/me0072.img      <--- Select this file
  /cdrom/me0072/me0072.trl
  /cdrom/me0072/me0072.nul

 Currently none of the header or trailer files are utilized.  Only
 reading and updating of the image data is supported.  It is not possible to 
 create these files, nor is there any auxiliary information.  Also note that
 writing is only supported if the dataset is copied to disk from the CDROM.

 LGSOWG magnetic tapes can be read with the PACE program MIL,
 and LGSOWG CD-ROMs can be accessed via the PACE program LINK.

 See Also: MIL, LINK, FIMPORT

2	LIPS (Gould)

 Gould LIPS imagefile format is supported for import and export by
 the GDB library.  LIPS format is a simple pixel interleaved raster format
 with a 512 byte header.  There are three forms:  8-bit monochromatic,
 24-bit colour and 64-bit complex.  Of these only the first two
 are supported.

 No georeferencing information, or other auxiliary data is read or written 
 from or to LIPS files.  It is possible to LINK to LIPS files.

 See Also: FIMPORT, FEXPORT, LINK

2	MicroStation Design Files (DGN)

 MicroStation DGN files are supported by the GDB library for read access only.
 Both Raster and Vector data may be read from DGN files.  

 Three formats of Raster Imagery are supported:  Compressed Binary, Binary,
 and Byte. The georeferencing system for raster imagery is PIXEL.

 The supported vector entities are LINEs (3), LINESTRINGs (4), SHAPEs (6), and
 CURVEs (11).  Since a curve (with n points) is defined by interpolating 
 through all points, except for the first and last two, 
 curves are approximated as a polyline defined by the interior (n-4)
 points.

 Unsupported entities are ignored during the read operation.  For COMPLEX 
 elements, the individual elements which comprise a complex element are read 
 in as separate structures, not as one complete structure. The georeferencing 
 system for the vectors is PIXEL.

 See Also: LINK, FIMPORT

2	NITF
@keyword{NITF}

 A subset of the NITF (National Imagery Transmission Format) used by the
 the U.S. Government is supported by the GDB library for reading and writing.

 Single band, uncompressed, 8-bit unsigned data can be processed.
 Lookup or pseudocolour tables are not supported to date.

 NITF files where the Image Coordinate System is G (Geodetic) or C (Geocentric)
 will have 'LONG/LAT' Georeferencing when read by FIMPORT.  All other 
 Georeferencing is output as None or imported as 'PIXEL'.  (UTM Georeferencing
 has not been implemented to date.)

 NITF files can be generated with FEXPORT.

 See Also: FIMPORT, FEXPORT


2	NTX (Caris Interchange format)
@index{NTX (Caris Interchange format)}{NTX Format}
@keyword{NTX}

 Caris Vector Interchange (NTX) files are supported by the GDB library for 
 read access only.  The supported vector entities are CurvedLines (1), 
 Point-to-Point Lines (3), DashedLines(4), TextWithPosition (6), 
 Names (7), Symbols (8) and SpotHeigths (11). 

 Unsupported entities are ignored during the read operation.

 The supported Ellipsoids are:
 
 - (CL66) Clarke 1866    
 - (INTL) International   
 - (AUST) Australian N.S.
 
 The supported Projections are : 

 - (LC) Lambert Conformal     
 - (ME) Mercator              
 - (PO) Polyconic             
 - (PS) Polar Stereographic   	 
 - (TM) Transverse Mercator   
 - (UM) Universal trans. Merc.
 - (GN) Gnomonic              
 - (SC) Simple Conic          

 The following attributes will automatically be created for each layer when 
 reading an NTX file:

 - Repcode: 	UserNumber    
 - GroupId: 	GroupId (Number of the entity)
 - Angle: 	Angle
 - TextString: 	TextString
 
2	PCIDSK
@keyword{PCIDSK}

 PCIDSK is fully supported by the GDB library.  It is the only file format
 which currently allows ``adding'' segments, and one of the few which allows
 data description fields to be extracted and saved to the file.

 The channel and segment description fields which appear in the Load and
 Save panels are related to the most current history records in the PCIDSK
 file.  When image or segment data is written to the file, a new history
 record is written with the current description and the name of the Works
 program.

 Currently there are no facilities in the Works programs for 
 performing database maintenance functions on a PCIDSK database such
 as deleting segments, deleting or adding channels, or modifying the
 georeferencing information.  These functions can only be performed
 using EASI/PACE programs.

 See Also: {WORKS|Data File|File Creat|PCI}Works Create Panel, CIM, PCIMOD, III

2	PPM
@keyword{PPM}{PGM}{PBM}{pbmplus}

 Raw PPM, PGM and PBM files are simple raster formats supported by the 
 GDB library.  ASCII formatted PPM, PGM and PBM files are not supported.  
 These files are an interchange format used by the popular `pbmplus' file 
 interchange utilities.  

 - PPM: RGB format, only 24-bit supported.
 - PGM: Greyscale, only 8-bit supported.
 - PBM: Bitmap, all supported.

 PPM, PGM and PBM files have no auxiliary information such as georeferencing,
 LUTs, or PCTs; however, georeferencing will be exported in an .aux file.

 These formats are supported for read, write and update.  The PPM and PGM
 files can be accessed with the LINK program.

 See Also: LINK, FIMPORT, FEXPORT

2	Raw Image Format
@keyword{Raw image format}{User described image files}

 The GDB library has a facility for reading and writing imagery in user
 described raw files.  The files are described to the GDB layer by a 
 complex naming convention.  This is not intended for interactive use,
 but may be important in some batch or scripted environments.

 The naming convention for raw files is:
  
  RAW:::filename xsize ysize bands [offset {8U/16U/16S/32R} {PIXEL/LINE/BAND}]
    [*CHANNEL chan_num {8U/16U/16S/32R} offset pixel_off line_off
						[swapped/unswapped]]*

 The absolute simplest file description would describe a band sequential
 file of 8-bit data that is tightly packed with no header.  For example,
 the following would describe the file ``raw.dat'' as being three bands,
 512 pixels by 512 lines.

  RAW:::raw.dat 512 512 3

 A slightly more complex form can be used to define any file that could be
 read with IMAGERD.  This adds the offset to the first byte of imagery, 
 the data type and the interleaving mode.  The following description defines
 the same file as the previous one but it explicitly states that the offset
 to the first byte of imagery is zero, and the data is 8-bit unsigned,
 band interleaved.

  RAW:::raw.dat 512 512 3 0 8U BAND

 Many file organizations cannot be described this way.  For instance, files
 with more than one data type, or files with spaces between bands or 
 byte swapped multi-byte data cannot be described this way.  In these cases,
 it is possible to describe the layout of each channel.  The following 
 description defines the
 same raw.dat files as in the previous two descriptions.  For each channel 
 a data type, image offset and swapping capability is provided.  

  RAW:::raw.dat 512 512 3 *Channel 1 8U 0      1 512 unswapped
                          *Channel 2 8U 262144 1 512 unswapped
                          *Channel 3 8U 524288 1 512 unswapped

 The offset is to the first byte of data in the channel,
 so channel two data starts at byte 262144 in the file.  The
 second offset is from one pixel of data on the same scanline
 to the next pixel of data on the same scanline.  The third offset is 
 the offset from the beginning of one scanline to the beginning of the
 next.  The swap flag indicates whether the data is in little endian
 order or not.  Little endian byte order has the least significant byte
 of the word first, and is found on Intel and VAX machines.  This is
 considered `swapped'.  Big endian machines such as the Motorola and
 sun are considered `unswapped'.  The default is the native byte order
 of the current machine.

 A more interesting example might be a 300x400 one-band file with little
 endian 16-bit unsigned data starting after a one block (512-byte) header.

  RAW:::testi2.dat 300 400 1 *Channel 1 16U 512 2 1024 swapped

 User defined raw files are supported for reading and writing.  Georeferencing
 (or Projection) information will be written to an auxiliary file which has
 the same name as the data file but with the extension ``.aux''.

 See Also: IMAGERD, PCIADD2, FEXPORT 

2	RST (Works ASCII RST)
@index{RST (text) Format}
@keyword{RST}

 The RST, ASCII Representation Style Table, files are supported by GDB for 
 read and write. The RST is used to attach a representation on vector 
 layers in some Works applications. It consists of a list of representation 
 styles (REPCode, integer value) with a graphical primitive and some 
 parameters for each REPCode in the following format:

  GDBRST 1.0 Representation Style Table
  #
  Table <Table_descriptive_name>
  Symbols <Symbol_dataset_filename>
  Groups
  <GroupId>, <Description>
  <GroupId>, <Description>
  ...
  ...
  <GroupId>, <Description>
  Repcodes
  <Repcode>,<Part_Number>,<GroupId>,<PrimId>,<Priority>,<Description>
  		<Parameter_name1> = <Value>
  		<Parameter_name2> = <Value>
		...
  		<Parameter_nameN> = <Value>
  <Repcode>,<Part_Number>,<GroupId>,<PrimId>,<Priority>,<Description>
  		<Parameter_name1> = <Value>
  		<Parameter_name2> = <Value>
		...
  		<Parameter_nameN> = <Value>
  ...
  ...
  EndTable

 Only one RST can be stored in each file and it is always in segment 1.

 An empty text file may be produced if exported from a file that does not
 contain an RST.


2	Siemens SICAD (.SQD)
@keyword{Siemens SICAD SQD}

 The GDB library supports Siemens SICAD .SQD vector files for import and
 export.  Only the line (ETYP=LY) and point (ETYP=PG1) structures are
 supported on import and export.  All other structures are
 silently ignored.

 There are a variety of attributes that could be extracted with SQD vector
 data; however, there is only one Attribute field per structure in the
 PCIDSK vector segment.  Currently the GDB library extracts the value of
 the SQD ENUM field as the attribute, and ignores the STU, EB, NAM, PKZ 
 and PNR fields.  On export, all fields except the ENUM are initialized to
 a legal value.

 Due to the loss of much of the attribute and structural information, it is
 generally not practical to import SQD files into EASI/PACE and then export
 them to SICAD again after performing some operations.  

 SICAD georeferencing information is lost when importing SICAD files, and
 a units string of METRE is assumed.

 See Also: FIMPORT, FEXPORT

2	SPANS Vector Archive
@keyword{Tydac SPANS VEC/VEH}
@index{SPANS Vector Archive format}

 The GDB library supports the SPANS Archive format for both read and write 
 operations.  The SPANS archive format consists of two files, which have a 
 common basename and .VEC and .VEH extensions.  The VEC file contains the 
 actual data, whereas the VEH is the header file and describes the contents 
 of the VEC file.  In addition there may be a .TBA file which contains
 the attribute records associated with the VEC/VEH file.

 All data sections are supported for read operations, any corresponding
 TBA file will also be read in.

 Only an ARCS data sections are written to the VEC file.  This
 vector file is written out in ARC format, without topology,
 and composed of unclean lines.  Any attributes assocaited with the arcs
 will be written out to the corresponding .TBA file.

 SPANS Vector files may not be modified.

 See Also: FEXPORT, FIMPORT, {..|}TBA

2	SPANS Raster
@keyword{Tydac SPANS RNH RNL}
@index{SPANS Raster}{RNH}{RNL}

 The Tydac SPANS raster format can store various raster data types including
 8-bit unsigned, 16-bit signed and 16-bit unsigned.  The GDB library
 supports SPANS Raster format for import and export.  SPANS Raster header 
 files have the extension .RNH.

 Of the many possible datatypes of SPANS Raster files, only 8U, 16U and 16S
 are supported.  All other data types, including some SPANS Raster
 files which run length encoded or ASCII encoded, are not supported.

 SPANS Raster files are supported by the LINK program.  Projection and 
 georeferencing information is supported on import and export for most 
 projection and ellipsoid types; however, there are cases that do not 
 translate between systems.

 SPANS Raster files do not contain any other auxiliary data items.  SPANS
 colour table files are not supported at this time.

 See Also: LINK, FEXPORT, FIMPORT

2	SPOTView GIS-GEOSPOT
@keyword{Spot Image}{GEOSPOT}

 The SPOTView GIS-GEOSPOT image format is a GIS ready image product 
 distribution format used by Spot Image.  The GDB library supports the
 SPOTView 4.0 format, now being distributed by some Spot Image distributor.
 The software has also been successfully used with some SPOTView 1.5 format
 datasets.

 The SPOTView distribution format includes a number of auxiliary files
 organized in two levels of directories.  In each subdirectory there should be
 one or more files ending in the extension .BIL and .HDR.  The .HDR file 
 contains georeferencing and structural information while the .BIL file
 contains just image data.  The user must select the .BIL file in order to
 access the dataset.

 Georeferencing information is handled for some projections; however, due
 to limitations in the available documentation some Spot Image supported
 projections are not currently full supported.

 There is no support for exporting in SPOTView format.

 See Also: FIMPORT

2	Sun Raster
@keyword{Sun Raster}

 Pseudocoloured, greyscale, and RGB Sun Raster files are supported 
 by the GDB library.  This is a format generated by several Sun utilities
 as well as many popular scanners.

 Sun Raster files will have one or three image channels, and may 
 contain a PCT, or three LUTs depending on the configuration. Sun Raster
 files do not contain any georeferencing information, nor do they
 contain any fields describing the data.  Sun Raster files can be 
 created using the ``New'' menu selection in Works programs.

 See Also: {WORKS|Data File|File Creat|Sun}Works Create Panel,
	   LINK, FIMPORT, FEXPORT

2	TARGA
@keyword{Targa Raster} 

 Two forms of Targa raster files are currently supported:  
 uncompressed True-Color and Black & White formats.  Color-mapped images 
 and any run-length encoded images are not supported at this time.

 For Targa True-Color files 16, 24, and 32-bit images are all supported.
 A True-Color file will appear as a three channel file, each file will
 contain either the Red,Green or Blue component of the color image.
 Black & White Targa files will appear as a file with a single channel.

 The GDB layer also supports the output of Targa files.  Again only
 True-Color and Black & White images are supported for write operations.
 The GDB layer will only output True-Color 24-bit files, which require as
 input three 8-bit channels.  If a single channel is to be written out,
 the output will be a black and white Targa file.

 See Also: {WORKS|Data File|File Creat|Sun}Works Create Panel,
	    LINK, FIMPORT, FEXPORT
2	TBA (.tba)
@keyword{TBA}
 TBA is a database (attribute table) format associated with Spans VEC/VEH
 files.  It is supported for import and export by the GDB library, 
 and is treated as a single vector layer with no vertices.

 TBA files have no concept of a georeferencing system, and the produced
 attribute layer will be marked as being in the METRE georeferencing system.

 TBA files can be imported with FIMPORT, and exported with FEXPORT. 
 
 TBA files are associated with VEC/VEH files and need not be directly
 read or written. Reading in a VEC/VEH file with an associated tba file
 will read in the TBA file automatically. Similarly writting out vectors
 to VEC/VEH format will produce a TBA file for the attributes.


 See Also: FIMPORT, FEXPORT, {..|}SPANS Vector Archive

2	TIFF
@keyword{TIFF}

 Several common forms of TIFF files are supported by the GDB library.
 In particular, it is possible to read TIFF B (Bitmap), TIFF R 
 (RGB), TIFF P (Palette), and TIFF G (Greyscale).  Files with none,
 LZW, or PackBits compression are supported, as well as those with
 some other compression schemes.

 TIFF G files contain one channel of imagery; TIFF B files contain
 a single bitmap; TIFF P files contain a single channel of imagery 
 and a pseudocolour segment.  To properly view the image, it is
 necessary to load both the imagery and the segment, and place the display in 
 pseudocolour mode.  TIFF R files contain three image channels (RGB).  

 TIFF files do not support LUTs.  No descriptive data is extracted from 
 the TIFF file, nor is any written back.  

 Georeferencing information in GeoTIFF format can be written to, and 
 extracted from TIFF files.  GeoTIFF is a new (1995) standard expected to 
 be adopted by many companies in the geomatics industry.  PCI's support
 includes UTM, State Plane, Geographic, Lambert Conformal Conic, Transverse
 Mercator, Mercator, and Oblique Mercator. 

 Any uncompressed TIFF file that can be read, can also be written
 to; however, this is not true of compressed TIFF files which are
 read only.

@ifhlp
 The Tagged Image File Format (TIFF) was designed to be an
 extendible, all-purpose standard for image interchange.  A TIFF
 file consists of an image, with a list of information tags
 describing the image.  A variety of image orderings is
 possible using TIFF files, as well as various types of 
 compression.  The TIFF format is extendible, as new information
 tags can be added at will, and TIFF file readers are required
 to ignore tags they do not understand.

 Because it is realistically impossible for a TIFF reader to
 read all possible TIFF format files, a small number of TIFF
 subset classifications have been developed.  Requirements for
 reading and writing these classified files have also been
 developed.

 Relevant classes are TIFF B (Bilevel or Bitmap), TIFF G
 (Grey level), TIFF P (Palette or Pseudocolour) and TIFF R
 (RGB).  You should use FIMPORT to read any of these formats.
 FEXPORT is capable of generating any of these TIFF formats.

 The supported classes have a variety of possible compression
 schemes, of which LZW, PackBits, CCITT 3 Fax and CCITT 4 Fax
 are known to work.  PCI's TIFF support does not include 16-bit
 data, or any other data sizes besides 1-bit (bitmap) and 8-bit.

 PCI would like to thank Sam Leffler and SGI for providing the
 ``libtiff'' TIFF library, on which all of PCI's TIFF support is 
 based.

 A libtiff based suite of public domain Unix tools for dealing 
 with TIFF files is available by anonymous ftp from sgi.com on 
 the Internet.  These tools include functions to compress and 
 uncompress TIFF files using most known TIFF compression schemes.

 Additional information on the TIFF format was extracted from the
 book ``Practical Image Processing in C'' by Craig A. Lindley from
 Wiley Professional Computing.  
@end

 See Also: {WORKS|Data File|File Creat|TIFF}Works Create Panel, 
	   FIMPORT, LINK, FEXPORT

2	UK National Transfer Format (.NTF)
@keyword{NTF}{Ordnance Survey}

 The GDB library supports for import most NTF 2.0 format files provided by the
 Ordnance Survey in the United Kingdom.  All Ordnance Survey
 data provided in 1994 and on will be in NTF 2.0 format.  Earlier
 formats are not guaranteed to work.

 The Land-Line, Oscar, 1:625000 Topographic, 1:250000 Topographic,
 1:50000 Contour and 1:50000 DTM may be supported, though some
 structures may be lost with some of these formats.  
 Boundary-Line files are not supported.  All of these formats are
 vector with the exception of the DTM files which are raster height fields
 constructed from contour information.

 There are a variety of attributes that can be extracted with vector
 data; however, there is only one Attribute field per structure in the
 PCIDSK vector segment.  To get around this limitation, NTF files are
 represented as having two segments.  Each contains the same vectors, but
 with different attributes.  Segment 1 of an NTF vector file will contain
 vectors with the feature code number as the attribute.  The second segment
 will contain vectors with the value as the attribute.  

 All georeferenced information for NTF files is in the UK's National Grid 
 projection which is a type of Transverse Mercator.  The GDB library will
 represent vector and raster data with the appropriate TM projection
 characteristics:

  - Reference Longitude: 49.0
  - Reference Latitude: 2.0
  - False Easting: 400000
  - False Northing: -100000
  - Scale: 0.9996012717
  - Ellipsoid: Airy 1830 (E009)

 There is no support for updating, or writing NTF files, nor can the DTM
 files be LINKed to.

 See Also: FIMPORT

2	UNIDSK-VMS
@keyword{UNIDSK-VMS}

 UNIDSK-VMS image files are partially supported by the GDB library.
 UNIDSK-VMS is a file format used primarily by the Canada Center for
 Remote Sensing (CCRS) and related facilities.  It is related to the
 original PCI UNIDSK format, which was replaced by PCIDSK several 
 years ago.

 UNIDSK-VMS is supported for read and update access, but new UNIDSK-VMS
 files cannot be created.  No georeferencing, or auxiliary information is
 extracted from UNIDSK-VMS files.

 Only 8-bit BIL, 16-bit BIL, 8-bit BSQ, and 16-bit BSQ UNIDSK-VMS files
 are currently supported, although only 8-bit BIL has been tested.  There
 are no PACE programs specifically for reading or writing UNIDSK-VMS 
 files but the LINK program does support this format.

 See Also: LINK

2	VICAR
@keyword{VICAR}{AVIRIS}

 VICAR format can be read by the GDB library.  VICAR format is used for 
 AVIRIS data (Airborne Visible/Infrared Imaging Spectrometer).

 Writing or updating VICAR format is not supported by the GDB library.

 See Also: FIMPORT

2	WorldMap
@keyword{WorldMap}{JEBCO}

 WorldMap is an image format originating in the former Soviet Union.  Data is
 distributed in the United States by JEBCO.  The example files provided
 by JEBCO are 1 band, and the assumption is that all WorldMap files
 are 1 band.

 WorldMap files are supported for reading and updating imagery.  It is
 also possible to LINK to WorldMap files.  No georeferencing or other 
 auxiliary information is supported for WorldMap files.  It is also not 
 possible to create WorldMap files.

 WorldMap scenes consist of a number of related files, including a header
 file which must have the extension .rh, and the raw imagery file which
 must have an extension of .bsq or .bsf.w.  Any of these three files
 may be selected to access the WorldMap image.

 See Also: LINK, FIMPORT

2	xBase (.dbf)

 xBase is a database (attribute table) format supported by many PC 
 applications, and is a standardized form the of DBase IV file format.  
 It is supported for import and export by the GDB library, and is treated
 as a single vector layer with no vertices.

 xBase files have no concept of a georeferencing system, and the produced
 attribute layer will be marked as being in the METRE georeferencing system.

 xBase files can be imported with FIMPORT, and exported with FEXPORT.  

 See Also: FIMPORT, FEXPORT, {..|}Arc/Info Shapefile
 
2	X Window Dump
@keyword{X Window Dump}

 Pseudocoloured, greyscale, and RGB X Window dump files are supported 
 by the GDB library.  This is a format generated by the widely available
 xwd program available on many Unix workstations for capturing screen 
 dumps.  

 X Window Dump files will have one or three image channels, and may 
 contain a PCT, or three LUTs depending on the configuration.  X Window
 dump files do not contain any georeferencing information, nor do they
 contain any fields describing the data.  X Window Dump files can be 
 created using the ``New'' menu selection in Works programs.

 See Also: {WORKS|Data File|File Creat|X Win}Works Create Panel, 
           LINK, FEXPORT, FIMPORT

1	Programs Using GDB Library

 The following programs are intended to be able to access many, or all
 GDB file types, and may be considered to be generic import and export
 programs.

 See Also: LINK, FIMPORT, FEXPORT, IIIC, CDLC, {IWORKS}ImageWork
